home *** CD-ROM | disk | FTP | other *** search
/ Mac Mania 6 / MacMania 6.toast / / Tools&Utilities / MacGzip 1.0□ / MacGzip 1.0 / Mac Docs / File Formats < prev    next >
Text File  |  1995-10-08  |  5KB  |  81 lines
  1.  
  2. A Macintosh file can store data in two different ways. One of them is known as 'Resources' (descriptions of windows, icons, etc) and the other ('Data')  contains application data (text, graphics, etc); so all Macintosh files consist of a Data Fork and a Resource Fork (optional). From the computer point of view, is like every file was actually two files.
  3.  
  4. If we consider the need to store the Finder info too (Finder label, status flags, etc) we have 3 parts for every file. Other operating systems don't support this (one could say their files consist only of a Data Fork), so every time you transfer a Macintosh file to a different OS you will lose the Finder Info and the Resource Fork for that file.
  5.  
  6. If you want to actually use the data in that OS, then all the valid information must be in the Data Fork: (example: a Macintosh JPEG image file can have Resources, for instance the preview and the finder custom icon; but these are irrelevant in a Unix machine; since you access the file in a different way)
  7.  
  8. This is what we call 'Binary transfer' (since gzip is a Unix compressor and gzip format holds compressed Unix data, to gzip a Macintosh file is analogous to transfer it to a Unix machine), so after the transfer you will get a file which exactly the contents of the Data Fork byte by byte.
  9.  
  10. This can be a problem in certain situations. Earlier we said text is in the Data Fork (usually), so you may think is enaugh to transfer it in binary mode.
  11. Well, this is no true for a simple reason: In binary data, every OS knows how to read it; the formats are well defined and the software is adapted to deal with it. But for text, every OS defines 'what' is text and how to use it, so every OS uses a different convention to mark the end of a line (and don't talk about char sets...).
  12.  
  13. There are two bytes which are used for this task:
  14.     CR (Carriage Return) and LF (Line Feed)
  15.  
  16.         DOS uses <CR><LF>
  17.         Macintosh uses <CR>
  18.         Unix (and others) uses <LF>
  19.  
  20. So, Unix will see a Macintosh text file as a unique (and very long) line with some strange characters inserted periodically.
  21.  
  22. The 'ASCII' transfer mode will change every <CR> by <LF> (the reverse when the target is a Macintosh text file)
  23.  
  24. CR and LF aren't reserved bytes, so every binary file can use them (and they do), so if you transfer a binary file in ASCII mode; the chances are to get garbage...
  25.  
  26. In the other hand, you can alway convert a text file transmited in binary mode to the local conventions after the transfer; but is faster simply to transfer it right.
  27.  
  28. In most Unix machines there are utilities to make the tranlation of text files (unix2dos, dos2unix, fromdos, todos). For  Macintosh text files you can use "tr '\015' '\012'" as 'frommac' and "tr '\012' '\015'" as 'tomac'.
  29. And for DOS and Unix you can use a public domain utility named 'charconv', too.
  30.  
  31.  
  32. What about if you want to store a Macintosh file in a different Machine but you don't want to lose none of the info (for instance, an application)?
  33.  
  34. Then you can use a format which joins the two forks and the finder info in a new file with only Data Fork. There are several formats to do this (BinHex, MacBinary, etc); since BinHex uses only 7 bit codes (opposed to MacBinary, which uses all 8 bits) it is not a good choice for a compressor.
  35.  
  36. If once you have the MacBinary file in the non MacOS machine you decide you want to use the Data Fork, there are several ways to accomplish it.
  37.  
  38. You can get a macbinary translator. Usually this will give you two files (foo .data and foo.rsrc); you can install (in Unix) Columbia AppleTalk Package and use 'capit'; which will restore even Finder Info.
  39.  
  40. You can also use a program similar to this one:
  41.  
  42. /* Quick & (very) Dirty program to extract Data Fork from MacBinary */
  43. #include <stdio.h>
  44. #include <fcntl.h>
  45.  
  46. main(int argc, char **argv)
  47. {
  48.     int id, od;
  49.     long i;
  50.     char buf[128];
  51.  
  52.     id = open ( argv[1], O_RDONLY );
  53.  
  54.     read(id, buf, 128);
  55.     buf[2+buf[1]]=0x00;
  56.  
  57.     /* Data Fork lenght. Avoid byte sex problems */
  58.     i = buf[86] + 256 * ( buf[85] + 256 * ( buf [84] + 256 * buf[83]));
  59.  
  60.     od = open ( &buf[2], O_WRONLY | O_CREAT );
  61.  
  62.     for ( ; i>0 ; i-=128)
  63.         write( od, buf,  read ( id , buf, i < 128 ? i : 128 ));
  64.  
  65.     close(od);
  66.     close(id);
  67. }
  68.  
  69.  
  70. MacGzip's MacBinary mode will give you a file with .gz extension (just like binary and ASCII mode). It would be more correct to use .bin.gz; but this will make a suffix too long; anyway, when -N (save/restore original name) option is used; the saved name _has_ the .bin suffix; so you can know it is a MacBinary file (if you expand it using another program (not MacGzip) make sure you expand it in binary mode, and use -N for clarity).
  71.  
  72.  
  73. MacGzip can select the correct mode automatically for you; but you need to tell him how; the best way is to use Internet Config. You can read more about IC and Macintosh files in 'Suffix Mapping'
  74.  
  75. BTW, gzip files are binaries; ASCII transfer mode will mess them (usually you get a CRC error when you try to expand); and MacBinary will give you a file with 128 bytes of garbage at the start (you can skip them usin 'dd' in Unix) and more garbage at the end (MacBinary rounds file sizes to 128 bytes chunks). Most of the times, if you skip the 128 bytes header at the start, gzip will be able to decompress the file
  76.  
  77.  
  78.  
  79.  
  80.  
  81.